這系列文章的主題/目標是「教外行人用AI寫程式」。
所以「如何有效率的告訴AI該寫什麼樣的程式」才是重點，只要抓到要訣，即使是外行人也可以用AI寫出很獨特的程式，而不是「給我一個俄羅斯方塊」「給我一個噗噗鳥」「給我一個貪食蛇」「給我一個相簿本」....

Android初期縱容這種「一堆一點都不獨特的程式亂噴亂撒」的開發策略，為了收尾就不停推出更粗暴的管理補救辦法，這樣的模式很快會出現在Steam上。（糟糕，同時期在鐵人賽開兩個主題的副作用，忍不住要對著資訊界的各種愚蠢專案管理政策噴幾句話。）

回題。

程式設計並不只是程式設計。
上一篇文章講到一個例子說明「電腦與電腦程式懂的東西...」，繼續用這個例子。

電腦與電腦程式懂的是....（如何讓喇叭發出一聲Beeee。）
「開啟Port ＭＭ」「產生額外的執行序」「給額外的執行緒設定編號ＭＭ1」「產生資料串ＭＭ2（Beeee的資料格式）」「要求執行ＭＭ1跟Port ＭＭ進行傳輸請求」「要求執行緒從Port ＭＭ收到許可後開始連續向Port ＭＭ發送ＭＭ2、持續一秒鐘」「一秒鐘後，停止傳送，向Port ＭＭ發送關閉通知」「結束功能，結束執行緒ＭＭ」「回收記憶體」。
程式設計的難處在於這個流程裡的一些細節。

第一步「開啟Port ＭＭ」，（過去）在不同的硬體裝置上，「ＭＭ」可能會不一樣。
例如裝置Ａ的Port是101，而裝置Ｂ的Port是202。
所以程式在這地方會去分辨自己位於哪個裝置上，看看是裝置Ａ、裝置Ｂ、裝置Ｃ...還是裝置ＸＸＸ？...程式這樣寫合理嗎？
明顯不合理，因為「萬一裝置不在程式可以辨識的範圍，該怎麼辦？」
為了一勞永逸解決這種問題，所以有「韌體」，「韌體」會代勞處理「開啟Port ＭＭ」這個動作，程式只要告訴「韌體」需要開始進行某功能（讓喇叭發出一聲Beeee），「韌體」就會幫忙完成「開啟Port ＭＭ」，這時候寫程式就不再需要使用「開啟Port」這個功能（來讓喇叭發出一聲Beeee)，而是直接對韌體下指令（「讓喇叭Beeee一聲」）。

（但為什麼韌體聽得懂？後面會介紹API。）

程式的使用者只要確保自己的裝置安裝了正確的「韌體」，程式開發者只要確保自己有正確呼叫「韌體」，程式運行的「成功率」就會變得很穩定。

為什麼說是「成功率」？

因為功能可以被呼叫運行，並不表示運行結果會成功。

有一些用上面這個範例來解釋會很誇漲的情況存在，例如「要求執行ＭＭ1跟Port ＭＭ進行傳輸請求」，這件事情可能會有些五花八門的情況發生，例如....
C裝置的傳輸請求會Z毫秒後才回應，如果程式碼沒有設計成可以等待Z毫秒後才檢查回應結果，那程式在這裝置上永遠會運行失敗，因為「立刻檢查只會得到空回應，而沒有回應就不會執行接下來的功能」。
所以程式要為了C裝置而刻意在這地方設計成「會等待任意毫秒，直到收到回應」嗎？

廢話。

而且，「為什麼要設計成等待任意毫秒？不是Z毫秒嗎？」因為其他裝置可能會等待Z1毫秒，或甚至根本不確定何時會回應！

這種不確定性大大地增加了程式設計的困難與挑戰。

但這也開啟了一個可能性：程式設計領域需要的不僅僅只是「寫程式碼」的能力，還包含了對「裝置」的經驗與知識。

注意！

經驗先於知識。

不懂這個的意義嗎？

反正下一篇要開始寫程式了。還有時間慢慢體會。